COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂84-11-25 20:21
C00007 00003	∂84-12-08
C00011 00004	∂09-Dec-84  0829	ROD  	More, mumble  
C00012 ENDMK
C⊗;
∂84-11-25 20:21
To: EJG
From: Rod

Please make sure PW sends all the latest documentation that you and EB have
generated. In particular I need to see the inline CONS stuff
from EB.

Here are my current plans (sort of).

1. Tomorrow work on LAP spec (then disappear to Key West till Thursday
   (my fourth trip in  five weeks!)).

2. Generate a proposal for handling throw of multiple values--it is
   a little tricky to deal with interrupts that can call lisp in
   the middle. Does EB (or anyone) have anything written down on
   the general interrupt issue--I seem to recall there was something
   in his cons stuff. Also I'm hopeful of reducing the amount of shuffling
   that currently happens in tail recursive pass ons of multiple
   values. In addition I need to find a way to make MULTIPLE-VALUE-CALL
   and the current analysis model, where the stack height is always
   known at analysis time, peacefully coexist.

Post SUN arrival:

3. Install open coding for MAPCAR and friends (already written). This
   makes for much improved coding style in the compiler--before I thought
   it was hard and wanted the compiler to be able to compile itself without
   it.

4. Implement code literals for EB's cons. Also fix function call sequence
   to make use of PEA and remove an instruction.
   
5. Expand multiple values to full CL spec. (Have the alpha code done and
   ready to install.) Includes tricky business with THROW and UNWIND-PROTECT.

6. Make GO work through CATCH and UNWIND-PROTECT.
    (This enables special binds in DO bodies to work(!!), amongst
     other things.)

7. Handle &KEY in alpha (initially so we can use DEFSTRUCT).

8. Add closures (and flavor instance-vars).

9. Make everything else full CL spec.

10. Make all code it produces horrendously fast.


Maybe JK wants to know this and redirect my priorities.

Please don't delete this as I will want to refer to it.
Thanks.

∂84-11-29 00:40
To: ROD
From: EJG
Sounds good.  I don't understand the GO/CATCH issue completely - seems
like a lot of overhead.  EB and I are supposed to do a code review
for Primops on Monday - the code is almost all written, the spec is
lagging behind, and the test plan is so far an imagination figment.
I'll see if your priorities seem good to Jussi and others, and try
to make sure all current online doc gets sent with your Sun tape
(our 1/4" drive is still not hooked up, I think).  Anything you
want to see sooner could be phoned in via whitney, I guess.  (EB
moved the shortfloat sign bit from the high order secondary tag
bit to the low order - do you have preferences on this?)  Sun
was just checking on our ability to pay for yours, and claimed
they would have shipped already if not for a minor bank screw-up, now
fixed.  I'll be out of touch Friday and Saturday - phone Paul/Eric/Jussi
about anything that seems urgent...

∂84-11-29 11:05
To: EJG
From: ROD
ARRRRGGGGGHHHHH!!!! Still not shipped ?!!??
About GO: I didn't mena implement it with CATCH etc., but make it
work so you can GO outside of a pending CATCH or UNWIND-PROTECT
which is part of the CL defn.
∂84-12-08
To: EJG
From: Rod


I fixed the bug you reported. It was because the code was
(let ((x x)) ...). There were actually two bugs which both
got tickled in weird ways.

On other fronts:

1. You guys forgot to send me /usr/lib/lisp directory which includes
   things like the assembler and the trace package. A symbolic link
   to the regular assembler lets me compile, but I had to hack up
   my own trace...
 
2. In 68k-fung.lisp you forgot a whole bunch of ":effs nil" which
   makes for all sorts of extra stack munging. (Remember we
   made the default be t everywhere.) I changed my copy but its
   probably out of date now so you should change yours I guess.
   You can also declare ash& and lsh& to take fixnump arguments.

3. There's an new implication of this sub-primitive scheme I
   hadn't thought of before. It's often the case that, say,
   sys:fixnum-compare ends up with literal arguments even
   though the >& it came from didn't . This can happen
   quite easily due to the let variables of a transform
   getting removed for instance. So there needs to be callable
   versions of all these functions. I'll try to write them
   in the next day or two. The primary and secondary type
   test are going to be the killers.

4. I suspect you don't really want to declare arguments to
   be fixnums as in (a dreg fixnum), although it doesn't
   break anything at the moment it will in the future.

5. I see the compiler can't do "car" anymore. However it
   does seem to know about "%car". I assume this is a half
   installed scheme. But why do we need %car, when car will do?
   (see note 4 above).

6. The compiler can no longer do cadr, first, second etc.
   These used to be in commacs. Don't forget to put them
   somewhere.

7. I can't get any failures of the let variable elimination mechanism
   to happen, in the way which I remember EB reported to me a
   couple of weeks ago. Maybe I've remembered the symptoms wrong
   or maybe they were all instances of the (let ((x x))..) bug.
   Can you get EB to tell me again what was going wrong.
∂09-Dec-84  0829	ROD  	More, mumble  
I realized there are still some subtle bugs in the analyzer when
variables get shadowed. I think I have to make alphatization
uniquify all variable names...

∂09-Dec-84  2141	ROD  	car's %car's and dtp-cons    
A. I noticed that you and EB use different values for the primary data
   types (besides different names). Also his don't conform to the
   number=even scheme. I guess you really know this and will 
   sort it out this week, but just in case you forgot...

B. Can you ask EB to provide me with the following examples:
   1. The cases he told me about let vars not being removed.
      I can't get them to fail the way I remember he told me.
   2. The case that stimulated his Nov-29 changes to alpha.lisp.
      The changes broke some cases of normal macro expansion
      and I need to check my nnew changes work right on his examples.
   3. A couple of weeks ago he told me that the compiler sometimes
      complained that AND was undefined at the end even though
      everything compiled right. Complaints about non-apparent
      functions was one of the symptioms that led me to the bug
      fixed in 2 above, but never AND. Can he give me a specific
      example of worng complaints. (PRINT doesn't count, I found
      out why that one was happenning -- needed to change the load
      order at build time.)

C. Since car ==> %car has to be switchable offable, and since I
   assume %car ==> sys:pointer-ref-constant is going to stay on all the
   time, hte only reason not to change back to a switchable
   car ==> sys:pointer-ref-constnant is that you want to write code
   that mixes safe CAR's and unsafe %CAR's which will presumably
   be knwo to be safe by the programmer (just wanting %CAR's is not
    a good enough reason as you could gloabally turn on the switch.)
   So the only rationale I can see is that you want a priori known
   safe compiler macros to expand into %car's while the user's
   car's are being bullet proofed by the compiler. The question then
   is why not right car ==> sys:pointer-ref-constant *and*
   %car ==> sys:pointer-ref-constant where the first is switchable
   but the second is not. This leads to one less layer of
   macro expansion which will make the compiler faster.
   I guess the question then is that worth the trouble of making
   two copies?

Enough rambling...